This seems fine, but I wonder if it wouldn't be better for the trellis-over-cassandra-app to subclass TrellisConfiguration and add these methods there?

You tell me-- I know as much about Dropwizard as I do about playing poker: nothing. Should I close this and try that instead?

Nope, Java's bottom-of-the-barrel variance. TrellisApplication extends Application<TrellisConfiguration>, and TrellisCassandraApplication extends TrellisApplication, so I don't think I can also somehow TrellisCassandraApplication extends Application<TrellisCassandraConfiguration>. Or maybe I'm missing something?

Sorry-- misclick.

A better approach might be to add a @JsonAnySetter method to TrellisConfiguration:

@JsonAnySetter
public void set(final String name, final String value) {
    internalMap.put(name, value);
}

@JsonAnyGetter
public Map<String, String> any() {
    return internalMap;
}

That adds a simple extension point for any possible subclasses.

Where is internalMap? Is that to be added as well?

Yes, it's just some internal field. Call it whatever you'd like.

I'm not much with JSON; what about Map<String, Object>? Would that effectively account for nesting? I.e. with

@JsonAnySetter
public void set(final String name, final Object value) {
    internalMap.put(name, value);
}

@JsonAnyGetter
public Map<String, Object> any() {
    return internalMap;
}

I haven't ever used that precise construct with Jackson serializations, but I don't see why it wouldn't work. It should be trivial to set up a test -- just add some additional fields to one of the configuration files in ./src/test/resources

Didn't work at all, not even with simple Strings:

io.dropwizard.configuration.ConfigurationParsingException: /Users/ajs6f/Documents/trellis/trellis/trellis-app/bin/test/config1.yml has an error:
  * Unrecognized field at: cassandraAddress
    Did you mean?:
      - assets
      - resources
      - namespaces
      - cacheMaxAge
      - binaries
        [12 more]

So maybe that works for Jackson's semantics, but not for Dropwizard's particular concrete processing code?

Again, I know little about Dropwizard, but I'm beginning to suspect that we're running up against its intentional limits-- it seems to be for building single apps, not ecosystems. Extensible config is really not a concern if you are build a single app.

Hang on-- I had a misconfig in my code. Testing further...

Okay, how's that?

incidentally, I tried going:

public class TrellisApplication extends Application<TrellisConfiguration> {

=>

public class TrellisApplication<T extends TrellisConfiguration> extends Application<T> {

but all of the test classes exploded with:

The constructor DropwizardTestSupport<TrellisConfiguration>(Class<TrellisApplication>, String, ConfigOverride, ConfigOverride, ConfigOverride) is undefined

Not really sure what's going on there, but I think the issue is that Class<TrellisApplication> isn't provably a supertype of Class<TrellisApplication<T extends TrellisConfiguration>> (or the other way 'round), so the compiler pukes into its own shirt. Shall we just rewrite the whole app in Scala?

@ajs6f I tried running the test and it works for me using IntelliJ. One side note is that the @RunWith(JUnitPlatform.class) is not required since the test class is written for JUnit5. AFAIK, that annotation invokes the JUnit4 runner.

Thanks much @christopher-johnson ! I didn't actually write that test, just added a few limes to it, so I'll let @acoburn remove that annotation. Unless, @acoburn , you'd like me to do it here?

I will fix those probs in two seconds, but just so you know-- I ran ./gradlew check install to check this and it passed fine. Do we need to couple checkstyleMain into check? I thought it already was?

That's odd. It could be that running this without clean means that the changes aren't caught. I definitely get the checkstyle errors when running ./gradlew clean check install

Okay, I'll keep an eye peeled. I might try making a few intentional faux pas and see which Gradle invocations catch them and which do not.